Skip to content

[bug]: Relax restricted peer access rules #9874

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ziggie1984 opened this issue May 28, 2025 · 5 comments
Open

[bug]: Relax restricted peer access rules #9874

ziggie1984 opened this issue May 28, 2025 · 5 comments
Labels
bug Unintended code behaviour p2p Code related to the peer-to-peer behaviour
Milestone

Comments

@ziggie1984
Copy link
Collaborator

ziggie1984 commented May 28, 2025

The new introduced access manager in LND 19 is very restrictive by disallowing new inbound and outbound connections (no channel peers) after a certain peer count threshold (30 by default). This can be exploited by consuming all available connection slots, thereby hindering our ability to establish new peer connections and open channels to new peers (or allowing new inbound capacity).

To address this, I propose the following adjustments to the access manager's behavior:

  1. Unrestricted Outbound Connections: We must always allow outbound connections, irrespective of the current peer count. This guarantees our node's continuous ability to initiate connections with new peers and expand its channel network.

  2. Conditional Inbound Connection Allowance: For inbound connections, a new peer should be granted a temporary grace period upon connection. During this brief time-window, the peer is expected to open a channel. If a channel is not established within this specified timeframe, the peer should be automatically disconnected.

@ziggie1984 ziggie1984 added this to the v0.19.1 milestone May 28, 2025
@ziggie1984 ziggie1984 added bug Unintended code behaviour p2p Code related to the peer-to-peer behaviour labels May 28, 2025
@yyforyongyu
Copy link
Member

We should increase the default and maintain it as is. Then any outbound connection initialized via connect can bypass this connection limit, and have its own limit - maybe a significantly larger value, but still it cannot be unbounded. This is similar to how bitcoind handles its connection resources.

For inbound connections, a new peer should be granted a temporary grace period upon connection. During this brief time-window, the peer is expected to open a channel.

This would be great but I don't think it's feasible without specs update - like how can a peer signal its intention to open channels?

@BhaagBoseDK
Copy link
Contributor

the restricted connections can be kept in a round robin queue, last in first out.

@ziggie1984
Copy link
Collaborator Author

This would be great but I don't think it's feasible without specs update - like how can a peer signal its intention to open channels?

I was thinking just giving the peer some time like for example 1 minute if he hasn't opened a channel by then we disconnect ?

@yyforyongyu
Copy link
Member

I was thinking just giving the peer some time like for example 1 minute if he hasn't opened a channel by then we disconnect ?

How can we distinguish them? This would mean we will disconnect all peers eventually?

@MegalithicBTC
Copy link

MegalithicBTC commented May 29, 2025

An LND user running something like an LSP routinely needs to allow hundreds of nodes to connect to it, indeed these nodes might be set "on startup" to automatically connect to the LSP.

Seems like some kind of "FIFO" would be necessary in this case, with some kind of logic like "when we reach the restricted limit, drop the oldest restricted connection to make room for the new one."

Or even more sophisticated could be -- because I think LND stores ping times -- an LRU-style or latency-aware eviction policy: cull the restricted peer with the worst (highest) ping time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unintended code behaviour p2p Code related to the peer-to-peer behaviour
Projects
None yet
Development

No branches or pull requests

4 participants